% -*- mode:     LaTeX -*- -------------------------------------------------- %
% File:         defsys.tex
% Description:  A Portable Defsystem
% Author:       Joachim H. Laubsch
% Created:       8-Sep-89
% Modified:     Tue Aug 11 12:05:21 1992 (Joachim H. Laubsch)
% Language:     LaTeX
%
% *************************************************************************
% Copyright (c) 1989, Hewlett-Packard Company
% All rights reserved.
%
% Use and copying of this software and preparation of derivative works
% based upon this software are permitted.  Any distribution of this
% software or derivative works must comply with all applicable United
% States export control laws.
% 
% This software is made available AS IS, and Hewlett-Packard Company
% makes no warranty about the software, its performance or its conformity
% to any specification.
% 
% Suggestions, comments and requests for improvements are welcome
% and should be mailed to laubsch@hplabs.com.
% *************************************************************************

\documentstyle{report}    % Specifies the document style.
\newcommand{\metavar}[1]{\mbox{$\langle\/$#1$\/\rangle$}} 


\title{A Portable System Definition Facility \\ for {\sf Common Lisp}
      }  
\author{Joachim Laubsch (laubsch@hplabs.hp.com)
      \thanks {This document describes an extended version of the
               portable {\tt defsystem} facility written by Douglas Rand
               (dsrand@mitre.org).}
}    

\begin{document}           

\maketitle
\begin{abstract}
In order to maintain a large system of modules with complex load and
compile time dependendies, a declarative and central representation of
a system, its subsystems and modules is preferrable to one where these
dependencies are associated with a particular module (e.g. by {\tt
require} and {\tt provide}).  Since in Lisp the definition of other
languages is a frequently used programming technique, the load and
compile time dependencies are also parameterised by the compile or
loader to be used for a module or system.  The System Definition
Facility described in this document is intended to meet this
need.

\end{abstract}


\paragraph {Syntactic convention:} Brackets [ ], braces \{\}, stars *, vertical bars
$|$ are metasyntactic marks. Brackets denote defaults, braces optional
elements, vertical bars alternatives, and the star zero or more
repetitions. A symbol written in angle brackets, like \metavar{this}
denotes a syntactic variable.

\section* { Defsystem }

\begin{tabbing}
mmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmmmmmmm\=\kill
({\tt defsystem} \metavar{system-name} \>\>\>{\em macro} \\
       \> (\metavar{system-option}*)\\
       \> \metavar{module-description}*)
\end{tabbing}

A system named by the symbol \metavar{system-name} is defined. The
package of the symbol is significant (i.e. there may be several
systems with the same symbol-name).  The \metavar{system-name} and
its definition are added to the association list {\tt *all-systems*}.

\subsection* {System options}
\label{System-options}

\begin{itemize}
  \item {\tt :default-pathname} \\
    \{\metavar{directory} $|$ (\metavar{source-directory} .
\metavar{binary-directory})\} \\

  The \metavar{directory} is either a pathname or a string.  If it is
a string, it may contain {\sf UNIX} environment variables or {\sf
MacIntosh} logical directories.  This string is first converted by
{\tt expand-file-name}, a function which returns a string in which all
occurrences of
\$\metavar{environment variable} are replaced by the value of that
variable if defined.  Unless specified with each module, this is the
directory from which the source of the module will be retrieved and on
which the binary of the module will be stored.  The
\metavar{binary-directory} by default is determined by concatenating
the \metavar{source-directory} string with
{\tt *relative-binary-namestring*} (which is initially empty).

  \item {\tt :default-package} \{\metavar{package name} $|$ [{\tt nil}]\} \\
  	The default package to load or compile modules in, nil means the
	current	package.


  \item {\tt :needed-systems} \{(\metavar{system-name}*) $|$ [{\tt nil}]\} \\
  A list of subsystems which should also be loaded before the system
is loaded.

 \item 	{\tt :load-before-compile} \{(\metavar{system-name}*) $|$ [{\tt nil}]\} \\
 A list of subsystems needed for compilation.  If the system is
 compiled, and any of its modules needs recompilation, then these
 systems will be loaded.

 \item {\tt :default-load-module} \{ [T] $|$ \metavar{module-name}\} $|$ (\metavar{module-name} ...) \\ 
The default is that all modules will be loaded (T) when
{\tt load-system} is called.  It is possible to indicate a single
\metavar{module-name} which by itself may cause loading of any
set of modules, possibly by having a {\tt :load-after} description,
(see section \ref {ModuleDescriptions} below).  A list indicates the
names of the modules to be loaded in that order.  {\tt nil} means that
no module will be loaded.

 \item {\tt :compiler} \{ [{\tt compile-file]} $|$ \metavar{compiler}\}\\ 
An alternate function for compilation, \metavar{compiler},
can be specified.  It is expected that at compilation time of the
system a function named  \metavar {compiler} with
the argument list: {\tt (input-file \&key output-file)} is defined.
 
 \item {\tt :loader} \{ [{\tt load}] $|$ \metavar{loader}\}\\
An alternate function to load a file, \metavar{loader}, can be
specified.  It is expected to be defined as a function of one
argument, the pathname of the file to be loaded.  The default
\metavar{loader} is the CL function {\tt load}.

 \item {\tt :suffixes} \{ [{\tt *suffixes*}] $|$ (\metavar{source} .
\metavar{binary}) \}\\
If specified, the pathname-type of the source (binary) file is
\metavar{source} (\metavar{binary}), otherwise it is the {\tt car}
({\tt cdr}) of {\tt *suffixes*}.  (The variable {\tt *suffixes*} is a
cons of source and binary type that depends on the implementation.)

 \item {\tt :documentation} \{ \metavar{string} \}\\
The documentation can be retrieved using the function 
\begin{quote}
{\tt ds:system-documentation}.
\end{quote}
\end{itemize}

\paragraph{Subsystems}  The definition of a 
{\em subsystem} --- the value of the {\tt :needed-systems} and
{\tt :load-before-compile} keywords --- will be automatically loaded if a
file with the name:
\begin{center}
 {\tt  \metavar{system-name}-sys.\metavar{source-type} }\\
\end{center}
can be found in the directory of {\tt *default-pathname-defaults*} or any
directory on the list of {\tt *system-directories*}.  

{\tt *system-directories*} is an (initially empty) list of pathnames
or strings denoting directories.  For example, looking for a system named
{\tt GNU} would cause the file named {\tt GNU-sys.l} to be loaded.
The pathname-type \metavar{source-type} is dependent on the {\sf
Common Lisp} implementation, ``l'' in this case. 

  
\subsection* {Module Descriptions}
\label{ModuleDescriptions}

The rest of the {\tt defsystem} form (\metavar{module-description}*)
is a description of modules.  A module corresponds to a single file, a
module's name is the same as the {\tt pathname-name} of the
corresponding file.  The module load order is implied by the order of
the module descriptions in the {\tt defsystem} form.

 A module description may be a string naming a file or a list whose
first element is the string naming a file and the rest is a set of
keywords and values.  Each keyword names a module option. The module
options are:

\begin{itemize}
  \item {\tt :recompile-on} \{ \metavar{module-ref} $|$  (\metavar{module-ref}*)\} \\
                \metavar{module-ref} is either a string naming a module that the
		described module depends on or a list of the form 
		\begin{center}
		(\metavar{System name} \metavar{Module name} ..)
		\end{center} 
		which lists modules to be found in the
 		system named in \metavar{module-ref}.

		In the first case the referenced module must be part
 		of the current system or any of the subsystems of the
		current system (mentioned with the {\tt :needed-systems} or
		{\tt :load-before-compile} keywords). The search for
		the module begins in the current system and proceeds
		with subsystems in {\tt :needed-systems} and 
		{\tt :load-before-compile}.


		If one of the
                listed modules is newer than the described module, then
		the described module will be recompiled.  In this case the
                recompile dependencies will be loaded first.

                This may cause recursive recompilation, e.g. if {\tt foo}
 		depends on {\tt bar} and {\tt bar} is out of date 
		then {\tt bar} will be recompiled, etc.  

  \item {\tt :load-before-compile} \{ \metavar{module-ref} $|$  (\metavar{module-ref}*)\} \\
                These are  modules  that  are  loaded  before  recompiling  the
                current module.

  \item {\tt :load-after} \{ \metavar{module-ref} $|$  (\metavar{module-ref}*)\} \\
                This  is  a  useful  option only for loading modules during
                compilation since the load order will normally be satisfied
                during a {\tt load-system}.  E.g. a module mentioned
 		in the list of {\tt :load-before-compile} modules may
		require other modules to be loaded first.  Such
		modules should be mentioned with {\tt :load-after}.
		The chain of {\tt :load-after} relations is followed until
		a loaded  module is found.

  \item {\tt :load-always} \{ \metavar{module-ref} $|$ (\metavar{module-ref}*)\} \\
		This is an abbreviation for {\tt :load-before-compile}
		and {\tt :load-after} with identical arguments.

  \item {\tt :compile-only} \{[{\tt nil}] $|$ T\} \\
                The module will only be loaded for compilation of the system.
                This is usually true for files with just macros.

  \item {\tt :type} \\
     \{[{\tt :lisp}] $|$ {\tt :lisp-source} $|$ {\tt :lisp-binary} $|$ {\tt :lisp-example} $|$ {\tt :text} \} 
	\begin{description}
	  \item [{\tt :lisp}] The module will be compiled and loaded.
	  \item [{\tt :lisp-source}] Lisp source code to be loaded but
		never compiled.
          \item [{\tt :lisp-binary}] Compiled Lisp code to be loaded only.
	  \item [{\tt :lisp-example}] Lisp code to be neither compiled nor loaded.
	  \item [{\tt :text}] Text (e.g., documentation) not part of any program.
	\end{description}
		

  \item {\tt :pathname} \{\metavar{directory} $|$ (\metavar{source-directory} .
\metavar{binary-directory})\} \\ 
                If specified, it is the  pathname-directory in which
		this module will be found.  It may be the cons of a
		source and a binary pathname-directory in case one
		wants source and binary in different directories. 
		The default pathname of a module is the {\tt
		default-pathname} of its system.

  \item {\tt :package} \metavar{package-name} \\
                A string or symbol specifying what package to load or
 		compile this module in.  It defaults to the system's 
		default package.

  \item {\tt :compiler} \{ \metavar{compiler}\}\\ 
    The default for \metavar{compiler}, is the \metavar{compiler} of this
	module's system (see \ref{System-options}), unlesss the module
	is of type {\tt :lisp or :lisp-example} where it defaults to
	[{\tt compile-file}].

 
  \item {\tt :loader} \{ \metavar{loader}\}\\
    The default for \metavar{loader}, is the \metavar{loader} of this
	module's system (see \ref{System-options}), unlesss the module
	is of type {\tt :lisp or :lisp-example} where it defaults to
	[{\tt load}].

   
  \item {\tt :suffixes} \{ [{\tt *suffixes*}] $|$ (\metavar{source} .
\metavar{binary}) \}\\
   Like above (\ref{System-options}), but specific to this module.

\end{itemize}


\section* {Undefine a system}

\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmmm\=\kill
({\tt undefsystem} \metavar{system-name})       \>\>\>{\em macro} 
\end{tabbing}

{\tt undefsystem} removes the definition of a system from
{\tt *all-systems*}.

\section* {Loading a system}
\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt load-system} \metavar{system-name}   \>\>\>{\em function} \\
	\>\{{\tt :reload} \>\{ [nil] $|$ T \}\}\\
	\>\{{\tt :if-source-newer} \>\{ :load-binary $|$ [:load-source] \}\}\\
	\>\{{\tt :include-components} \>\{ nil $|$ [T] \}\}\\
	\>\{{\tt :preview} \>\{ [nil] $|$ T \}\}\\
	\>)
\end{tabbing}

      {\tt load-system} loads the modules of a system, possibly by
calling itself recursively for all included subsystems.  If no {\tt
:default-load-module} argument was provided in the definition, all
modules will be loaded, otherwise the modules whose names were given
as the argument to {\tt :default-load-module} are loaded.  The order
of loading is the order provided in the system definition (but this
may be overridden by {\tt :load-after} modules provided with each
file.  Modules which are described to be {\tt :compile-only} or have
the {\tt :type} {\tt :text} or {\tt :lisp-example} are not loaded.

 The variable {\tt *loaded-systems*} keeps a record of all names of
systems that have been loaded.

\begin{itemize}
  \item {\tt :reload} [nil]:  If T then force a full reload of everything.
  \item {\tt :if-source-newer} [{\tt :load-source}]: If both a source file
and a binary file exist for a module and the source file is newer, by
default the module is loaded from the source file, except if the value
of {\tt :if-source-newer} is {\tt :load-binary}.
  \item {\tt :include-components} [T]:  If T call {\tt load-system} on 
  the subsystems mentioned with  {\tt :needed-systems}.
  \item {\tt :preview} [nil]:  If T just print names of modules
	  that would have to be loaded, to load this system.
\end{itemize}

\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt system-loaded-p} \metavar{system-name}   \>\>\>{\em function} \\
\end{tabbing}

 {\tt system-loaded-p} returns two values, the first is T if the
system is loaded.  The second value is T if the system is loaded, but
needs a reload due to updates in any source file of a module which is
part of the system and loaded by {\tt load-system}.  Otherwise
the second value is Nil.

\section* {Compiling a system}

\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt compile-system} \metavar{system-name} \>\>\>{\em function} \\
	\>\{{\tt :recompile} \>\{ [nil] $|$ T \}\}\\
	\>\{{\tt :include-components} \>\{ nil $|$ [T] \}\}\\
	\>\{{\tt :reload} \>\{ [nil] $|$ T \}\}\\
	\>\{{\tt :preview} \>\{ [nil] $|$ T \}\}\\
	\>)	
\end{tabbing}

The {\tt compile-system} function will compile the system of the given
name.  If no system definition by that name is found on {\tt
*all-systems*}, an attempt to automatically load a definition-file is
made (see section \ref{System-options} above).  The system modules are
compiled in their specification order.  The default compiler is the CL
function {\tt compile-file}, but any other function may be specified
as the system option {\tt :compile} (see section
\ref{System-options}).  It is possible to call {\tt compile-system}
with other keyword arguments.

\begin{itemize}
  \item {\tt :recompile} [nil]\\
  Compiles all modules requiring recompilation.  If the {\tt
:recompile} keyword is T all recompilations occur regardless
of 'need'.  Need is determined by the date-time of the respective
binary and source files.
  \item  {\tt :include-components} [T] \\
  If T then call {\tt compile-system} on {\tt :needed-systems} of the 
  current system.
  \item  {\tt :reload} [nil] \\
  If T then always reload any needed modules.\
  \item {\tt :preview} [nil]:  If T just print names of modules
	  that would have to be compiled to compile this system.
\end{itemize}

\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt system-compiled-p} \metavar{system-name}   \>\>\>{\em function} \\
\end{tabbing}
Returns {\tt Nil} if the system contains a module that needs to be
recompiled or a needed-system that does not satisfy {\tt
system-compiled-p}, otherwise {\tt T}.


\section* { Systems needed by a system }
\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt system-needed-systems*} \metavar{system-name} \{ {\tt Nil} \}) \>\>\>{\em function} \\
\end{tabbing}

({\tt system-needed-systems*} \metavar{system-name} {\tt Nil}) will return 
the names of the systems supplied at its definition with the
{\tt :needed-systems} argument --- ``the directly needed systems''.

  ({\tt system-needed-systems*} \metavar{system-name})
returns the set of system names which are in the transitive closure of
this ``directly needed system'' relation.


\section* { Iterating over the modules of a system }
\begin{tabbing}
mmm\=mmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmmmm\=\kill
({\tt domodules} (\metavar{module} \metavar{system-name}\>\>\>\> {\em macro} \\
 \>\> \{{\tt :recursive-p \{ [nil] $|$ T \}}\}) \\
 \> \metavar{body})
\end{tabbing}

In the \metavar{body} of {\tt domodules} \metavar{module} will be
successively bound to the source file names of the modules of the
system named \metavar{system-name}, and --- in case {\tt :recursive-p T} is
specified --- all the modules in the transitive closure of the {\tt
needed-systems} relation.

For example,
\begin{quote}
	{\tt (domodules (m 'nll-core) (xref:xref-file M))}
\end{quote} 
will call {\tt xref:xref-file} file on every module of the system {\tt
nll-core}.


\section* {Compiling a module}

\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt compile-module} \metavar{module-name} \>\>\>{\em function} \\
	\>\{{\tt :system} \>\{ [nil] $|$ \metavar{system-name}\}\}\\
	\>\{{\tt :reload} \>\{ [nil] $|$ T \}\}\\
	\>\{{\tt :preview} \>\{ [nil] $|$ T \}\}\\
	\>)	
\end{tabbing}

Compile the module named by the string \metavar{module-name} and any
modules which this module depends on and need to be recompiled.  If no
{\tt :system} argument is supplied, an attempt is made to find the
system where this module was defined among {\tt *all-systems*}.  If a
\metavar {system-name} is supplied and the system is undefined, an
attempt is made to load the definition (see \ref{System-options}).  By
default, needed modules which are already loaded will not be reloaded.

As with {\tt compile-system}, the default compiler is {\tt
compile-file}, but any other function may be specified as the module
or system option {\tt :compile} (see section \ref{System-options} and
\ref{ModuleDescriptions}).  It is possible to call {\tt compile-module}
with other keyword arguments which will be passed on to the module's
compiler.


\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt module-compiled-p} \metavar{module-name} \>\>\>{\em function} \\
	\>\{{\tt :system} \>\{ [nil] $|$ \metavar{system-name}\}\}\\
\end{tabbing}

{\tt module-compiled-p} returns {\tt T} if its source is older than
its binary and every module which this module depends on satisfies
{\tt module-compiled-p}, otherwise {\tt Nil}.

\section* {Loading a module}

\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt load-module} \metavar{module-name} \>\>\>{\em function} \\
	\>\{{\tt :system} \>\{ [nil] $|$ \metavar{system-name}\}\}\\
	\>\{{\tt :reload} \>\{ nil $|$ [T] \}\}\\
	\>\{{\tt :if-source-newer} \>\{ :load-binary $|$ [:load-source] \}\}\\
	\>\{{\tt :preview} \>\{ [nil] $|$ T \}\}\\
	\>)	
\end{tabbing}

Load the module named by the string \metavar{module-name}. 

 If no {\tt :system} argument is supplied, an attempt is made to find
the system where this module was defined among {\tt *all-systems*}.
If a \metavar {system-name} is supplied and the system is undefined,
an attempt is made to load the definition (see
\ref{System-options}). 

 The keyword {\tt :reload} --- which defaults to {\tt T} --- specifies
whether loading should happen regardless of the module already been
loaded.  If the module's description contains any
:load-after modules, these will also be loaded (and so on
recursively).

 If both a source file and a binary file exist for a module and the
source file is newer, by default the module is loaded from the source
file, except if the value of {\tt :if-source-newer} is {\tt
:load-binary}.


\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmmm\=\kill
({\tt module-loaded-p} \metavar{module-name} \{{\tt :system} \metavar{system-name}\}\>\>\>{\em function} 
\end{tabbing}

 {\tt module-loaded-p} returns two values, the first is T if the
module is presently loaded.  The second value is T if the module is
loaded, but needs a reload due to updates in the source files of the
module or any other module mentioned with {\tt :load-after} or {\tt
:load-always} in its description.  Otherwise the second value is {\tt
Nil}.

\section* {Show a system}

\begin{tabbing}
mmmmmmmm\=mmmmmmmmmmmmmmm\=mmmmmmmmmmmmm\=\kill
({\tt show-system} \metavar{system-name})  \>\>\>{\em function}
\end{tabbing}

The function {\tt show-system} produces a pretty output of the system
description.  If a \metavar {system-name} is supplied and the
system is undefined, an attempt is made to load the definition (see
\ref{System-options}).  An attempt is made to detect cycles in the
{\tt :load-before-compile} and {\tt :load-after} order of the modules
of this system and all the system it needs.

\section* {Examples of system definitions}

{\tt \begin{verbatim}
;; Make sure that defsystem is loaded
(require "P-defsys"
         (format nil "~A/defsys/P-defsys"
                     (environment-variable "CL2LOADPATH")))

;---------------------------------------------------------------;
; define system NLL-UTIL and its modules
;---------------------------------------
(defsystem NLL-UTIL
    (:default-pathname ("$nll/util/" . "$nll/bin/")
     :needed-systems (NLL-COMPILE))
  "kb-interface"
  "parse-expr-from-string")
\end{verbatim}}

Note that the {\tt :default-pathname} of system {\tt NLL-UTIL} is a
cons of pathname strings, for source and binary respectively.  The
source files are found in {\tt "\$nll/util/"}, while the binary files
are found in {\tt "\$nll/bin/"}.  Pathnames may contain {\sf UNIX}
environment variables.  The modules are simply names of files.


The following system definition makes use of more features.  It allows
automatic loading of system definitions, introduces some dependencies
among modules, and finds some module in a different subsystem:

{\tt \begin{verbatim}

;; Directories to search for system definitions
(pushnew (pathname (expand-file-name "$nll/compile/"))
         *system-directories* :test #'equal)

;---------------------------------------------------------------;
; Define system NLL and its modules
;----------------------------------
(defsystem NLL
    (:default-pathname ("$nll/nll/cl2/" . "$nll/bin/")
     :load-before-compile (NLL-COMPILE NLL-UTIL)
     :needed-systems (NLL-COMPILE NLL-UTIL) )
  "nll-domain"
  ("nll-grammar" :recompile-on "nll-domain")
  "nll-binding"
  ("nll-normlz"  :load-before-compile ("nll-domain" "nll-grammar"))
  ("nll-subst"   :load-before-compile "nll-domain")
  "nll-drt"
  ("nll-interface" 
   :pathname ("$nll/nll/" . "$nll/bin/")
   :load-before-compile ("nll-domain" "nll-grammar")
   :recompile-on "kb-interface"))
  ("var-generator" :pathname ("$nll/nll/" . "$nll/bin/")))

\end{verbatim}}

After compiling and loading the NLL system, we can observe its state by:

{\tt \begin{verbatim}
(show-system 'NLL)

;;; System: NLL is loaded.
;;; It needs NO update.

;;; Load-before-compile: NLL-COMPILE NLL-UTIL 
;;; Needed Systems: NLL-COMPILE NLL-UTIL 
;;; Default Pathname: ("$nll/nll/cl2/" . "$nll/bin/")
;;;
;;; Module: "nll-domain"  Loaded
;;; Module: "nll-grammar"  Loaded
;;;    Recompile-on: "nll-domain" 
;;; Module: "nll-binding"  Loaded
;;; Module: "nll-normlz"  Loaded
;;;    Load-before-compile: "nll-domain" "nll-grammar" 
;;; Module: "nll-subst"  Loaded
;;;    Load-before-compile: "nll-domain" 
;;; Module: "nll-drt"  Loaded
;;; Module: "nll-access"  Loaded
;;; Module: "nll-interface"  Loaded
;;;    Load-before-compile: "nll-domain" "nll-grammar" 
;;;    Recompile-on: "kb-interface" 
;;;    Pathname: ("$nll/nll/" . "$nll/bin/")
;;; Module: "hpnl-get"  Loaded
;;;    Pathname: ("$nll/nll/" . "$nll/bin/")
;;; Module: "var-generator"  Loaded
;;;    Pathname: ("$nll/nll/" . "$nll/bin/")

\end{verbatim}}

\end{document}


